[译]关于证书，我所知道的一切——网站

原文:All I Know About Certificates -- Websites

在上一篇文章中，我们了解了客户端的作用以及它们对证书验证的责任。最后，让我们来谈谈网站。 我们已经讨论了许多关于证书颁发机构和客户端之间的问题，但最常见的问题是与网站相关的问题——许多网站都遇到过这个问题：证书已过期。

网站需要确保两件事：

  1. 确保他们的证书不会过期。
  2. 保护私钥不被泄露。如果其他人获得了私钥，证书就失去了“只有我才能证明我是谁”的意义。在向 CA 申请证书时，只提交公钥以供签名，因此只有网站才应该持有私钥。

别忘了更新证书！

第一点似乎很明显，但许多网站都遇到过类似的问题（这表明大多数团队……组织得不好）。一个隐藏的因素是所有证书都有到期日，包括根 CA 证书和中间 CA 证书。网站需要确保证书链中的每个链接都没有过期。

问题是证书的有效期为两年，两年后……大多数人会记得续订（如果你在大公司工作过，你可能知道要记住“两年后做某事”有多难）。

所以，Let's Encrypt 想出了一个绝妙的办法：我们颁发的所有证书都只有 90 天的有效期，没有例外！（显然，Let's Encrypt 真的是个很棒的组织！）

这种方法有两大优势：

  1. 私钥，就像密码一样，每 90 天更换一次，这更加安全。
  2. 谁喜欢每隔三个月就要经历这个过程呢？这就鼓励网站使用自动更新流程，证书每 60 天更改一次，这样就不太可能出现问题。

私钥保护

私钥至关重要，因为任何人只要获得它就可以欺骗所有客户端——声称自己是网站。因此，确保密钥不被泄露至关重要。

但如果它被泄露了呢？私钥部署在客户端可以直接访问的服务器上。如果服务器受到攻击，私钥可能会被泄露。毕竟，常在岸边走，哪有不湿鞋！

撤销已发出证书

此时，您可能会注意到另一个问题：假设一个网站的证书还有 6 个月的有效期，但是私钥被泄露了，导致部署了一个假网站。到目前为止我们讨论的方法无法阻止假网站，因为它已经获得了证书（可以从原始站点直接下载并部署），并且可以与客户端建立 TLS 连接。该证书由合法 CA 颁发，并且完全有效。

客户只能撤销 CA，但是撤销 CA 不切实际——其他没有泄露密钥的网站也会受到影响吗？

因此，我们需要一个机制来撤销已颁发的证书。

目前有两种主流方法：CRL 和 OCSP。

原则上，证书颁发机构本身会携带这些信息，通知客户端在验证证书时应该访问这个 URL 列表来检查它们正在验证的证书是否在撤销列表中。如果是的话，就不应信任它。

CRL

在 X509v3 扩展中，您可以找到有关 CRL 和 OCSP 地址的信息。例如，使用 CRL，您可以使用以下命令从下载的 DigiCert 证书中获取 CRL 地址：

$ openssl x509 -in digicert_tls_rsa_sha256_2020_ca1.pem -noout -text | grep "X509v3 CRL Distribution Points" -A 4
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl3.digicert.com/DigiCertGlobalRootCA.crl

然后，从此 CRL 地址下载内容（以 DER 格式），并使用 openssl 将 DER 格式解码，查看此 CA 撤销的一些证书：

$ curl -sS http://crl3.digicert.com/DigiCertGlobalRootCA.crl | openssl crl -inform DER -text -noout

你可以使用证书颁发机构提供的 URL 查看已吊销的 DigiCert 证书。 吊销证书

OCSP

OCSP 采用类似的原则。

但是这种方法有没有问题呢？客户端必须通过向 URL 发送额外请求来验证证书的有效性，这会引入一些问题（以使用 OSCP 为例）：

  1. 由于需要额外的时间来处理 CA 请求，网站性能会降低；CA 的 OCSP 服务器可能会成为热点，并且可能被客户端压垮。
  2. 隐私问题：CA 将知道客户端访问了哪些域名。
  3. 潜在的安全问题：如果 CA 的 OCSP 服务宕机，客户端有两个选择：
    • 忽略验证并继续信任目标站点——这将使 OCSP 失效。持有吊销证书的证书持有人可能会破坏 CA 的 OCSP 服务或阻止客户端访问 OCSP 来继续使用他们的证书。
    • 不信任目标站点——这将使目标站点因 CA 问题而无法使用，这对站点来说是不可接受的。

OCSP 装订

OCSP 装订可以解决上述问题。它的核心原则如下：

  1. 该网站定期查询 CA 的 OCSP 服务，以确认其证书未被撤销，并获取 OCSP 响应。
  2. 当客户端访问该网站时，该网站会附带证书提供 OCSP 响应，证明证书未被撤销。

这消除了客户端与 CA 之间的依赖关系，解决了上述问题。

但是，如果该网站伪造了 OCSP 响应怎么办？

由于 OCSP 响应由证书颁发机构签名，客户端必须验证此签名以确认 OCSP 响应确实来自证书颁发机构，所以无法伪造。

您可以使用以下命令查看 OCSP 响应：

openssl s_client -connect kawabangga.com:443 -status -servername kawabangga.com

这里是 OCSP 响应的内容示例：

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: D5FC9E0DDF1ECADD0897976E2BC55FC52BF5ECB8
    Produced At: Aug 28 12:31:36 2023 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: EC4A2797F8915935139678B3E8C8A21D097B312E
      Issuer Key Hash: D5FC9E0DDF1ECADD0897976E2BC55FC52BF5ECB8
      Serial Number: 4BEA45B1F5C6C0310D047BC9EB5449FA
    Cert Status: good
    This Update: Aug 28 12:31:36 2023 GMT
    Next Update: Sep  4 11:31:35 2023 GMT

    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        5c:e0:44:17:a0:84:e1:5d:83:f5:0e:ad:18:2d:da:98:8a:be:
        9d:38:bd:f6:9a:d5:82:c2:14:08:2f:ac:6b:b4:78:4e:25:bc:
        a0:55:19:9b:75:b9:e8:54:d5:79:fa:a8:9b:ab:7a:3f:37:b0:
        9d:8d:f5:d4:67:95:80:e1:cd:bf:d5:ac:5f:fc:8c:22:a7:0f:
        2c:35:0a:de:4f:a9:63:67:ce:59:0f:f1:b7:9d:69:e9:dc:ce:
        06:7b:64:a0:60:19:bf:48:2e:af:f4:5c:85:69:54:4e:71:d0:
        09:75:0d:c5:54:0b:d8:49:1f:bf:18:65:97:03:2d:01:88:bf:
        9b:48:c5:30:f3:f5:59:34:b6:b5:89:81:6f:b0:01:e4:9a:26:
        6b:4d:51:0b:e7:12:86:33:8a:4e:cc:f4:4e:80:b7:63:29:df:
        6c:c6:8b:2e:2f:c1:6f:60:25:7d:4b:5b:4e:9f:48:9d:d0:8a:
        08:25:3d:e2:c0:2c:83:d4:5f:3c:66:4d:0d:71:da:19:c8:b5:
        58:64:b6:98:9f:46:f2:e4:a0:1c:e3:3b:a1:74:59:41:02:51:
        5d:74:43:31:24:02:d2:02:d6:ca:a5:ff:f2:ad:e7:87:89:83:
        40:ec:38:b4:90:1b:92:d3:36:23:f4:71:0d:02:c7:47:14:8f:
        d3:dc:d6:ff
======================================

因此，如果客户端收到网站发出的 OCSP 响应，则可以直接验证它；如果没有收到响应，则会向 CA 查询。如果接收到但未验证，则终止连接，并且不信任该网站。唯一的问题是在证书撤销后延迟撤销，这是可以接受的。

HTTP 公钥固定

网站还可以实现一种称为 HPKP（HTTP 公共密钥固定）的技术，其中网站在响应客户端请求时，会包含一个名为 Public-Key-Pins 的 HTTP 请求头。这个键是证书的公钥的哈希值。哪个证书？它可以是该站点自己的证书、中间证书或 CA 的根证书。一旦返回这样的 HTTP 响应，它就会告诉客户端只信任该证书（如果锁定 CA 的根证书，则会告诉客户端只信任由该 CA 颁发的证书）。这有助于防止其他人发布伪造的证书。

例如，如果我们的网站 super-bank.com 与一个证书颁发机构有很强的信任关系，但是 super-bank.com 担心其他证书颁发机构会为其签发证书，那么当客户端访问该站点时，它可以锁定证书颁发机构的根证书。这意味着该站点只使用由 CA A 签发的证书，即使信任其他证书颁发机构签发的任何证书，也很可能是伪造的！

但是，如果网站需要更改证书呢？客户端可能不再信任它。因此，如果使用 HPKP，则必须存在备份密钥；否则，HPKP 将无法生效。

证书透明

证书透明 (CT) 是一个需要客户端、颁发机构和网站支持的概念，这就是为什么它最后才被讨论。

它解决了什么问题？

CT 解决了证书颁发机构错误地为其他网站签发证书的问题。一些 CA 有着臭名昭著的混乱的内部管理。例如，有一篇文章讨论了作者如何从 WoSign 获得了像 github.io 这样的域名的证书，该证书后来由于其问题而失去了 Mozilla 和 Google 的信任。WoSign 甚至试图上诉，声称它只为中国用户提供服务（基本上说，“中国人只会骗中国人”），但上诉被驳回。不值得信赖的 CA 无法控制其范围，糟糕的管理可能会对全球网站和用户的安全造成影响。

为了防止此类问题，谷歌发起了证书透明项目。 该项目旨在解决颁发证书时权威机构滥发证书的问题。 有关 CT 的更多详细信息，请参阅其 官方网站 提供的清晰解释。 CT 以下是各方需要做什么的简化说明：

  • 当签发证书时，CA 必须在 CT 数据库中记录发出的证书，并且 CT 会提供已签名的时间戳（SCT）。CA 将包含 SCT 的已签名证书发送回网站。
  • 用户访问网站时只会信任带有 SCT 的证书。这确保了所有受客户端信任的证书都记录在 CT 数据库中。
  • 网站可以监视 CT 数据库以查看是否未经其许可就为其域签发了任何证书。

这样，任何 CA 都不能在网站不知情的情况下秘密为网站颁发证书，从而确保客户端只信任那些经过适当记录和监控的证书。

这是一系列关于证书的文章，希望你们在这里学到了一些东西。